• 专利附录
  • 专利说明
  • 权利要求
  • 类似技术
  • 同族专利
  • 引用文献
  • 法律状态
  • 优先权
    • 专利摘要:
    A method of managing user accounts (CU) in an application (APP) of an application provider (1), comprising the following steps, performed by an identity provider (2) sharing a trust relationship with the provider of application (1): - receiving (24, 44) an authentication proof request (PAT) for authenticating a user (USR) trying to access the application (APP), said user (USR) being registered with of the identity provider (2) - obtaining (25, 45) from a local database (3) of the user data (USR), said data including authentication data (DAT) and data of the user right of access (DAC) - authenticating (26, 46) the user (USR) using the authentication data (DAT) - determining (27, 47) the right to access the application (APP) by the user (USR), using the access right data (DAC) - determining (28, 48) the existence or absence of a user account (C U) associated with the user (USR), by querying an external database (4) managed by the application provider (1) - if the user (USR) has the right to access the application (APP) and that there is no user account (CU) associated with the user (USR): ○ trigger (29) the provisioning of the user account (CU) with an entity (1, 9) ○ Generate (30) User Authentication Proof (PAT) (USR) ○ Send (31) said proof of authentication (PAT) to the application provider (1).
    公开号:FR3021177A1
    申请号:FR1454303
    申请日:2014-05-14
    公开日:2015-11-20
    发明作者:Christophe Guionneau
    申请人:Evidian SA；
    IPC主号:
    专利说明:

    [0001] TECHNICAL FIELD OF THE INVENTION The present invention relates to the field of application service providers ("Application Service Providers") such as "cloud" applications or software as a service. (SaaS, "Software as a Service"), that is, hosted applications.
    [0002] BACKGROUND OF THE INVENTION An application provider is a provider capable of providing users with a hosted application that can be used over a network. Because these hosted applications are often billed for use and / or available for a limited time, application providers require authentication of users attempting to access the application. In addition, application providers generally allow authentication to be delegated to entities named identity providers where users are registered through authentication delegation and identity federation mechanisms. This delegation requires a previously established trust relationship between the application provider and the identity provider. Groups of users, for example companies, therefore have the option of installing an identity provider to perform user authentication. It is then the responsibility of the identity provider to optimize the creation (called provisioning thereafter) and destruction (called deprovisioning thereafter) user accounts based on actual use, including to reduce the number of licenses to buy from the application provider.
    [0003] Most known solutions are the use of a rights manager and user roles to provision or de-provision a user account when a user acquires or loses access rights to the application . If this solution actually makes it possible to perform the de-provisioning at the moment when the information of loss of right is known, it does not make it possible to optimize the provisioning as much as possible of the real use: indeed, the user can acquire the right long before its use, or never use its right of access to the application. At a given moment, there are therefore always more users provisioned (that is to say users associated with a user account) than users who actually use the application. On-the-fly provisioning solutions exist, but they must be installed on the application provider side. These solutions rely on user attributes conveyed by protocols for communicating authentication evidence between the identity provider and the application provider. The most used protocols are SAML protocols ("Security assertion markup language"), 0Auth or OpenID. These solutions therefore depend on the goodwill of the application providers to implement them. In addition, they are limited to provisioning and do not take into account de-provisioning.
    [0004] GENERAL DESCRIPTION OF THE INVENTION The object of the invention offers a solution to the problem mentioned above, by proposing a method for managing user accounts in a hosted application, making it possible to optimize the provisioning of user accounts.
    [0005] According to a first aspect, the invention therefore relates to a method for managing user accounts in an application of an application provider, comprising the following steps, performed by an identity provider sharing a relationship of trust with the provider of application: - receive an authentication proof request to authenticate a user trying to access the application, said user being registered with the identity provider - obtain from a local database of data on the user, said data comprising: authentication data and access right data - authenticating the user with the authentication data - determining the user's right to access the application using the data of the user access right - determine the existence or absence of a user account associated with the user, by querying an external database managed by the insane application manager - if the user has the right to access the application and there is no user account associated with the user: - trigger provisioning of the user account with an entity - generate authentication evidence associated with the user - sending said proof of authentication to the application provider.
    [0006] With the method according to the invention, the user accounts are provisioned at the moment when the users who have the right to access the application actually wish to access the application. User accounts are not created systematically as soon as a user obtains a right to access the application. In addition, this method is implemented by the identity provider, so there is no need for intervention on the side of the application provider. The method according to the invention may have one or more additional characteristics among the following, considered individually or in any technically possible combination.
    [0007] In one embodiment, the method comprises the following step: if the user does not have the right to access the application and there is a user account associated with the user, trigger the deprovisioning of the user account with the entity.
    [0008] Thus, if the user has lost his access rights to the application, his account is deleted when he wants to access it. In one embodiment, the entity is the application provider, the identity provider providing account provisioning or deprovisioning instructions to the external database. In this embodiment, the identity provider performs the provisioning or the deprovisioning itself by using interfaces and protocols made available by the application provider and providing all the information necessary for the creation of the account. It is noted that the necessary actions, the protocols and formats to be implemented depend on each application provider. Hosted application providers provide a set of interfaces and guides for performing these actions, use standard or proprietary protocols, and some provide online commands or executables to perform these actions.
    [0009] In one embodiment, the entity is an external management component, the external management component providing account provisioning or deprovisioning instructions to the external database. In this embodiment, the identity provider does not perform the provisioning or deprovisioning itself, but delegates it to the external component, for example a component of the identities and accesses, which triggers workflows ("workflow"). in English) provisioning or deprovisioning. The external component uses the interfaces and protocols made available by the application provider and provides all the information needed to create the account.
    [0010] In one embodiment, after provisioning or unprovisioning a user account, the identity provider updates user account information, indicating the accounts associated with the application provider and the accounts associated with the application provider. user.
    [0011] In one embodiment, the identity provider performs a global verification step, comprising: for each user registered with the identity provider, obtaining from the local database access rights data relating to the identity provider; user, - determine a list of accounts to de-provision, based on access rights and user account information - trigger the de-provisioning of accounts from the list of accounts to de-provision. Global auditing ensures that provisioned accounts are associated with users who still have the necessary rights or roles to hold an account, and any accounts that do not meet this condition are deprovisioned. The de-provisioning is then carried out either directly by the identity provider or by the external management component.
    [0012] In one embodiment, the identity provider performs a reconciliation step, comprising: - obtaining from the external database a list of provisioned accounts - comparing the user account information with the list of accounts to be provisioned - updating user account information based on the result of the comparison. Reconciliation can detect desyncs and generate alerts or correct inconsistencies.
    [0013] In one embodiment, the identity provider performs an account deletion step, comprising: - obtaining a user's access rights data modification information - determining a list of accounts to de-provision, depending on the changed access rights data and user account information - triggering the de-provisioning of accounts from the list of accounts to de-provision. Thus, when the identity provider is made aware that a user loses his rights or roles necessary to the possession of an account, a de-provisioning is triggered. The de-provisioning is then carried out either directly by the identity provider or by the external management component. According to a second aspect, the invention relates to an identity provider sharing a trust relationship with an application provider, adapted to implement a method according to the first aspect of the invention.
    [0014] According to a third aspect, the invention relates to a computer program, comprising a set of instructions, which when executed by a computer, causes the implementation of a method according to the first aspect of the invention.
    [0015] The invention and its various applications will be better understood by reading the following description and examining the figures that accompany it. BRIEF DESCRIPTION OF THE FIGURES The figures are presented only as an indication and in no way limitative of the invention. The figures show: in FIG. 1, a schematic representation of a network comprising an application provider and an identity provider according to one nonlimiting embodiment of the invention; - In Figure 2, a schematic representation of a user account management method of an application of the application provider, implementing the application provider and the identity provider.
    [0016] DETAILED DESCRIPTION OF AT LEAST ONE EMBODIMENT OF THE INVENTION Unless otherwise specified, the same element appearing in different figures has a unique reference. The present invention relates to a method for provisioning (creating) user accounts CU in an APP application of an application provider 1. Referring to Figure 1, the APP application is hosted in the application provider 1 and accessible via a network to USR users. The USR users considered in the embodiment described belong to structured grouping of persons, for example a company comprising employees, employees (users) with or without the right of access to the APP application according to a policy of rights and roles defined within the company. In order to access the APP application, USR users must authenticate themselves, which makes it possible to verify that they have the right to access the APP application.
    [0017] The company has an identity provider 2 to which the application provider 1 delegates the authentication function of the USR users of the company. For this, the application provider 1 and the identity provider 2 have previously established a trust relationship using a protocol such as SAML protocols, 0Auth, OpenID or other identity or delegation federation protocols. authentications. The identity provider 2 and the application provider 1 know each other, and the application provider 1, using the protocol 5, is able to request or obtain from the identity provider 2 a proof of authentication PAT for the USR users of the company.
    [0018] USR users have the necessary means to perform authentication against identity provider 2, for example via a password system, certificate, question-and-answer mechanism, etc. Identity provider 2 has a local database 3 (for example a relational database or an LDAP directory) in which the USR users of the company are registered. The set of USR users belonging to the company is listed in the local database 3. The identity provider 2 is able to connect to the local database 3 through an access protocol 8 such as LDAP / LDAPS (Lightweight Directory Access Protocol), Web Service, SQL (Structured Query Language), etc. This local database 3 is used by the identity provider 2 to verify the authentications, identify the USR users, and know the rights of the users. The local database 3 therefore comprises, for each user USR, DAT authentication data and access right data DAC searchable by the identity provider 2.
    [0019] In addition, to create (provision) a user account CU, the identity provider 2 - or an external component 9 that the identity provider controls - provides provisioning information to an external database 4 managed by the provider of identity. application 1. This provisioning information is all the information necessary for the application provider 1 to be able to create a user account. Similarly, to destroy (or de-provision) a user account CU, the identity provider 2 or the external component 9 provides de-provisioning information to the external database 4. The de-provisioning information is all the information necessary to the provider of the application 1 so that it is able to determine the user account CU to delete. For the identity provider 2 or the external component 9 to communicate with the external database 4, the application provider 1 makes available to the identity provider 2 interfaces and protocols 6. The application provider 1 is able to interrogate the external database 4 by means of a dedicated protocol 7, for example the LDAP / LDAPS (Lightweight Directory Access Protocol), Web Service, SQL (Structured Query Language), and so on. The method according to one embodiment is shown with reference to Figures 2, 3 and 4, in different cases. In each of these cases, a USR user wishes to access the APP application. In a first case represented in FIG. 2, the user USR holds a PAT authentication proof previously sent by the identity provider 2. This case occurs for example when the user USR has already connected to the server. APP application and still has the right to access the app APP. In a first step 11, the service provider 1 receives an access request to the APP application. In a second step 12, the service provider 1 determines whether the USR user holds a PAT authentication proof. In a third step 13, following the determination of the holding of a PAT authentication proof by the user USR, the service provider 1 verifies the PAT authentication proof. The PAT authentication proof is checked with the information that the service provider 1 knows about the identity provider 2 that issued this proof. Identity federation and authentication delegation protocol mechanisms, such as SAML, 0Auth, OpenID, or other protocols, are used to verify evidence. In a fourth step 14, following the verification of the PAT authentication proof, the application provider 1 gives access to the APP application to the user USR. In a second case shown in FIG. 3, the USR user does not hold PAT authentication evidence, has the right to access the APP application, and does not have a CU user account. This case occurs for example when the USR user has never connected to the APP application although he has a right of access to the APP application. In a first step 21, the service provider 1 receives an access request to the APP application. In a second step 22, the service provider 1 determines whether the USR user holds a PAT authentication proof. In a third step 23, following the determination of the non-possession of a PAT authentication proof by the USR user, the application provider 1 determines which identity provider 2 is associated with the user. USR. The application provider 1 uses the mechanisms of the federation or delegation of authentication protocols to determine the identity provider 2 of the USR user. In another embodiment, the application provider 1 requests the information from the user USR. In another embodiment, the application provider 1 uses the specific naming of the service URLs to determine the associated identity provider 2. In a fourth step 24, the service provider 1 redirects the USR user to the identity provider 2. According to the federation and delegation of identity protocols used, in another embodiment, the application provider 1 sends a request directly to the identity provider 2. In both cases, whether the request comes from the user USR or from the application provider 1, the identity provider 2 receives a PAT authentication proof request. According to a fifth step 25, the identity provider 2 obtains from the local database 3 data on the user USR, comprising its authentication data DAT and its access right data DAC. In a sixth step 26, the identity provider 2 authenticates the user USR by means of the authentication data DAT. For this, the identity provider 2 verifies that the USR user is a declared user and has the means of authentication. Then, the authentication is performed, for example by means of a password, a certificate, a question-and-answer mechanism, etc. According to a seventh step 27, if the user USR is correctly authenticated, the application provider 2 determines whether or not he has the right to access the APP application, using the access right data DAC . The identity provider 2 thus verifies that the USR user has the necessary rights and roles to connect and use the APP application. Note that if the user USR fails to authenticate correctly, the process stops. According to an eighth step 28, the identity provider 2 determines the existence or the absence of a user account CU associated with the user USR, by interrogation of the external database 4 managed by the application provider. 1. The identity provider 2 therefore determines whether the user USR is already associated with a user account CU in the application provider 1, said user account CU having been previously provisioned by the identity provider 2 or by other means. For this, the identity provider 2 uses the interfaces and protocols 6 made available by the application provider 1. - According to a ninth step 29, following the determination of the existence of the right to access the APP application and the absence of a user account CU, the identity provider 2 triggers the provisioning of the user account CU. In a first embodiment, the identity provider 2 itself performs the provisioning using the interfaces and protocols 6 made available by the service provider 1 and providing all the information necessary for the creation of the account. In a second embodiment, the identity provider 2 does not itself perform the provisioning, but delegates it to the external component 9, for example an identity and access management component, which triggers provisioning instructions. The external component 9 uses the interfaces and protocols 6 made available by the service provider 1 and provides all the information necessary for the creation of the user account CU. According to a tenth step 30, following the correct authentication of the user USR by the identity provider 2, the determination of the right to access the APP application by the user USR, and the completion of the mechanism Provisioning leading to the creation of a user account CU in the application provider 1, the identity provider 2 generates a PAT authentication proof associated with the user USR. According to an eleventh step 31, the identity provider 2 sends the PAT authentication proof to the application provider 1 according to protocol 5 between the two parties. According to a twelfth step 32, the application provider 1 uses the information provisioned in its database 4 and gives access to the APP application to the user USR. In a third case shown in FIG. 4, the user USR does not hold PAT authentication proof, does not have the right to access the APP application, and has a user account CU. This case occurs, for example, when the user USR had the right to access the APP application, had already connected to the APP application, but then lost his right to access the APP application. In a first step 41, the service provider 1 receives an access request to the APP application. According to a second step 42, the service provider 1 determines whether the user USR holds a PAT authentication proof. In a third step 43, following the determination of the non-possession of a PAT authentication proof by the USR user, the application provider 1 determines which identity provider 2 is associated with the user. USR. The application provider 1 uses the mechanisms of the federation or delegation of authentication protocols to determine the identity provider 2 of the USR user. In another embodiment, the application provider 1 requests the information from the user USR. In another embodiment, the application provider 1 uses the specific naming of the service URLs to determine the associated identity provider 2. In a fourth step 44, the service provider 1 redirects the USR user to the identity provider 2. According to the federation and delegation of identity protocols used, in another embodiment, the application provider 1 sends a request directly to the identity provider 2. In both cases, whether the request comes from the user USR or from the application provider 1, the identity provider 2 receives a PAT authentication proof request. According to a fifth step 45, the identity provider 2 obtains from the local database 3 data on the user USR, comprising its authentication data DAT and its access right data DAC. In a sixth step 46, the identity provider 2 authenticates the user USR by means of the authentication data DAT. For this, the identity provider 2 verifies that the USR user is a declared user and has the means of authentication. Then, the authentication is performed, for example by means of a password, a certificate, a question-and-answer mechanism, etc. According to a seventh step 47, if the user USR is correctly authenticated, the application provider 2 determines whether or not he has the right to access the APP application, using the access right data DAC . The identity provider 2 thus verifies that the USR user has the necessary rights and roles to connect and use the APP application. Note that if the user USR fails to authenticate correctly, the process stops. According to an eighth step 48, the identity provider 2 determines the existence or absence of a user account CU associated with the user USR, by querying the external database 4 managed by the application provider. 1. The identity provider 2 therefore determines whether the user USR is already associated with a user account CU in the application provider 1. For this, the identity provider 2 uses the interfaces and protocols 6 made available to him by the application provider 1. - According to a ninth step 49, following the determination of the absence of the right to access the APP application but the existence of a user account CU, the identity provider 2 triggers the deprovisioning of the user account CU. In a first embodiment, the identity provider 2 itself performs the de-provisioning by using the interfaces and protocols 6 made available by the service provider 1 and providing all the information necessary for the destruction of the user account CU. In a second embodiment, the identity provider 2 does not perform the de-provisioning itself, but delegates it to the external component 9, which triggers deprovisioning instructions. The external component 9 uses the interfaces and protocols 6 made available by the service provider 1 and provides all the information necessary for the destruction of the user account CU. The USR user will not have access to the APP application. Moreover, the identity provider 2 constantly saves the state of the provisioned and deprovisioned CU user accounts for each user USR and each application provider 1 (an identity provider 2 can be in contact with several suppliers application 1). Thus, in a step 50, following a provisioning (step 29) or a de-provisioning (step 49), the identity provider 2 updates user account information, indicating the user accounts CU associated with the application provider 1 and the CU user accounts associated with the user USR.
    [0020] In a step 51, the identity provider 2 performs a global verification step. During this global verification step, for each USR user registered with the identity provider 2, the identity provider 2 obtains from the local database 3 access rights data relating to the USR user. Then, the identity provider 2 determines a list of user accounts CU to de-provision, according to the access rights and user account information CU. Finally, the identity provider 2 triggers the de-provisioning of the user accounts CU of the list of accounts to de-provision as described in step 49. This global verification step 51 can be performed on demand or automatically on change of the data of the account. access right DAC. Thus, identity provider 2 ensures that provisioned CU user accounts are properly associated with USR users who still have the rights or roles necessary to use these CU user accounts. In this case, CU user accounts are deprovisioned.
    [0021] In a step 52, the identity provider 2 performs a reconciliation step. In this reconciliation step, the identity provider 2 obtains from the external database 4 a list of provisioned user accounts CU. Then, the identity provider 2 compares the user account information CU with the list of accounts to be provisioned. Finally, the identity provider 2 updates the user account information according to the result of the comparison. This reconciliation step 52 may be performed on demand or automatically at regular intervals. The identity provider 2 then obtains from the application provider 1 the list of the accounts of the company and reconciles with the list of accounts known by the identity provider 2. This mechanism makes it possible to detect desynchronizations and the case appropriate to generate alerts or correct inconsistencies when they are detected. In a step 53, the identity provider 2 performs an account deletion step. During this account deletion step 53, the identity provider 2 obtains an access rights data modification information from a USR user. Then, the identity provider 2 determines a list of accounts to de-provision, including at least one account associated with the user. The list is determined based on the modified access rights data and the user's account information. Finally, the identity provider 2 triggers the de-provisioning of the user accounts CU of the list of accounts to de-provision. Thus, in the event that a USR user loses his rights or roles necessary to the possession of a CU user account, then a de-provisioning can be triggered using the account deletion mechanism.
    [0022] Thus, the method according to the invention offers the advantage of only creating the accounts at the moment of their actual use, of destroying the accounts which are no longer usable, and consequently of saving resources in terms of accounts declared in the application provider.
    权利要求:
    Claims (10)
    [0001]
    REVENDICATIONS1. A method of managing user accounts (CU) in an application (APP) of an application provider (1), comprising the following steps, performed by an identity provider (2) sharing a trust relationship with the provider of application (1): receiving (24, 44) an authentication proof request (PAT) for authenticating a user (USR) attempting to access the application (APP), said user (USR) being registered with the identity provider (2) obtaining (25, 45) from a local database (3) user data (USR), said data including authentication data (DAT) and data from a user access (DAC) to authenticate (26, 46) the user (USR) by means of the authentication data (DAT) determine (27, 47) the right to access the application (APP) by the user ( USR), using the entitlement data (DAC) determine (28, 48) the existence or absence of an associated user account (CU) to the user (USR), by querying an external database (4) managed by the application provider (1) if the user (USR) has the right to access the application (APP) and that there is no user account (CU) associated with the user (USR): - trigger (29) the provisioning of the user account (CU) with an entity (1, 9) - generate (30 ) a user-associated proof of authentication (PAT) (USR) - sending (31) said proof of authentication (PAT) to the application provider (1).
    [0002]
    2. Method according to the preceding claim, comprising the following step: if the user (USR) does not have the right to access the application (APP) and that there is a user account (CU) associated with the user (USR), trigger (49) the de-provisioning of the user account (CU) with the entity (1, 9).
    [0003]
    3. Method according to one of the preceding claims, wherein the entity (1) is the application provider (1), the identity provider (2) providing instructions for provisioning or deprovisioning account at the base external data (4).
    [0004]
    The method according to one of claims 1 or 2, wherein the entity (9) is an external management component (9), the external management component (9) providing provisioning or account deprovisioning instructions to the external database (4).
    [0005]
    5. Method according to one of the preceding claims, wherein after a triggering provisioning (29) or de-provisioning (49) of a user account (CU), the identity provider (2) updates (50) user account information, indicating the user accounts (CU) associated with the application provider (1) and user accounts (CU) associated with the user (USR).
    [0006]
    6. Method according to the preceding claim, wherein the identity provider (2) performs a global verification step (51), comprising: - for each user (USR) registered with the identity provider (2), obtain local database (3) user access right data (DAC), - determine a list of user accounts (CU) to de-provision, based on access rights (DAC) and user account information - trigger (49) the de-provisioning of user accounts (CU) from the list of accounts to de-provision.
    [0007]
    7. Method according to one of claims 5 or 6, wherein the identity provider (2) performs a reconciliation step (52), comprising: - obtain from the external database (4) a list of user accounts (CU) provisioned - compare user account information (CU) with the list of accounts to provision - update user account information (CU) based on the result of the comparison.
    [0008]
    The method according to one of claims 5 to 7, wherein the identity provider (2) performs an account deletion step (53), comprising: - obtaining access right data modification information ( DAC) - Determine a list of user accounts (CUs) to de-provision, based on modified access rights (DAC) data and user account information - triggering the de-provisioning of user accounts (CUs) ) from the list of accounts to de-provision.
    [0009]
    Identity provider (2) sharing a trust relationship with an application provider (1), adapted to implement a method according to one of claims 1 to 8.
    [0010]
    Computer program, comprising a set of instructions, which when executed by a computer, causes the implementation of a method according to one of claims 1 to 8.
    类似技术:
    公开号 | 公开日 | 专利标题
    EP3143747B1|2018-07-04|Method for managing user accounts in a hosted application
    US10122707B2|2018-11-06|User impersonation/delegation in a token-based authentication system
    US11228574B2|2022-01-18|System for managing remote software applications
    EP2819052B1|2018-08-01|Method and server for processing a request for a terminal to access a computer resource
    US9600679B2|2017-03-21|Techniques for resource operation based on usage, sharing, and recommendations with modular authentication
    KR101504801B1|2015-03-23|System and method for accessing private digital content
    US10367801B2|2019-07-30|Systems and methods for credentialing of non-local requestors in decoupled systems utilizing a domain local authenticator
    US9560080B2|2017-01-31|Extending organizational boundaries throughout a cloud architecture
    US20200366681A1|2020-11-19|Application-assisted login for a web browser
    WO2014199102A1|2014-12-18|Method for authenticating a terminal by a gateway of an internal network protected by an entity providing secure access
    EP2616983B1|2015-11-18|User account management device that can co-operate with a single sign-on device
    US9237156B2|2016-01-12|Systems and methods for administrating access in an on-demand computing environment
    Gastermann et al.2015|Secure implementation of an on-premises cloud storage service for small and medium-sized enterprises
    EP2881886B1|2019-09-18|Method for establishing a relationship of trust for resource sharing between two tenants in a cloud network
    EP1637989A1|2006-03-22|Method and system for the separation of accounts of personal data
    US9064289B2|2015-06-23|Service mediation model
    US10944561B1|2021-03-09|Policy implementation using security tokens
    Sayler2013|Custos: A flexibly secure key-value storage platform
    US20220043902A1|2022-02-10|Verifiable labels for mandatory access control
    Velthuis2017|New authentication mechanism using certificates for big data analytic tools
    WO2022010978A1|2022-01-13|Automation of user identity using network protocol providing secure granting or revocation of secured access rights
    WO2020016504A1|2020-01-23|Devices and methods for managing an attachment of a communication device to an operator network
    Ramey2016|Oracle Identity and Access Management Suite Overview
    KJ2013|Securing Storage Appliances via UNIX based Kerberos Authentication
    同族专利:
    公开号 | 公开日
    FR3021177B1|2016-06-10|
    EP3143747B1|2018-07-04|
    US9847991B2|2017-12-19|
    US20170078272A1|2017-03-16|
    WO2015173517A1|2015-11-19|
    EP3143747A1|2017-03-22|
    引用文献:
    公开号 | 申请日 | 公开日 | 申请人 | 专利标题
    US6144959A|1997-08-18|2000-11-07|Novell, Inc.|System and method for managing user accounts in a communication network|
    US7200674B2|2002-07-19|2007-04-03|Open Invention Network, Llc|Electronic commerce community networks and intra/inter community secure routing implementation|
    KR102223552B1|2013-12-04|2021-03-04|엘지디스플레이 주식회사|Organic light emitting display device and method for driving thereof|US10305885B2|2016-03-03|2019-05-28|Blackberry Limited|Accessing enterprise resources using provisioned certificates|
    US10277572B2|2016-04-12|2019-04-30|Blackberry Limited|Provisioning enterprise services provided by an infrastructure service server|
    CN107123043B|2017-05-11|2018-06-15|四川会计达人科技有限公司|A kind of inter-trade Accounting network method and system|
    EP3649105B1|2017-07-07|2021-09-01|Nouryon Chemicals International B.V.|Sodium methyl glycine-n,n-diacetic acid compound, process to prepare it and use thereof|
    US10931673B2|2017-09-19|2021-02-23|Amazon Technologies, Inc.|Policy activation for client applications|
    法律状态:
    2015-04-22| PLFP| Fee payment|Year of fee payment: 2 |
    2015-11-20| PLSC| Search report ready|Effective date: 20151120 |
    2016-04-22| PLFP| Fee payment|Year of fee payment: 3 |
    2017-04-21| PLFP| Fee payment|Year of fee payment: 4 |
    2018-04-23| PLFP| Fee payment|Year of fee payment: 5 |
    2019-05-28| PLFP| Fee payment|Year of fee payment: 6 |
    2020-05-27| PLFP| Fee payment|Year of fee payment: 7 |
    2021-05-26| PLFP| Fee payment|Year of fee payment: 8 |
    优先权:
    申请号 | 申请日 | 专利标题
    FR1454303A|FR3021177B1|2014-05-14|2014-05-14|METHOD FOR MANAGING USER ACCOUNTS IN A HOSTED APPLICATION|FR1454303A| FR3021177B1|2014-05-14|2014-05-14|METHOD FOR MANAGING USER ACCOUNTS IN A HOSTED APPLICATION|
    PCT/FR2015/051265| WO2015173517A1|2014-05-14|2015-05-13|Method for managing user accounts in a hosted application|
    EP15727701.3A| EP3143747B1|2014-05-14|2015-05-13|Method for managing user accounts in a hosted application|
    US15/311,009| US9847991B2|2014-05-14|2015-05-13|Method for managing user accounts in a hosted application|
    [返回顶部]